The general direction is looking fine functionality and code wise. I like that the PR applies the structure of services/contracts to this part of the application as well.

Apart from what I noted down next to the code, documenting the feature is a necessity.

Hey @oliverguenther thank you for this great and long awaited feature.

Disclaimer: I didn't check the code out. I simply read over the code changes.

One important thing that seems to be missing is the handling for existing tokens after the application got deactivated. I guess you have two options:

• have some sort of danger zone before the deactivation and tell the admin that this will delete all existing tokens. That is rather cheap to implement.
• check every API request, if the access token belongs to an OAuth application that is not deactive. That is expensive and probably not worth the effort.

Further, from the product perspective I see that client pretty generic and not mobile restricted. Thus I proposed a couple of changes (application name, redirect URI, ID).

While we are at it: Ideally we should tell client developers to implement "PKCE" to pretect the client from being intercepted by another app registering for the same redirect URI protocol. However, that is not in the responsibility of the OAuth provider, thus not strictly part of this PR.

I'll just reiterate @wielinde comments about security and overall approach.

That's a ton. Code looks sane for the intended purposes.